--------Partie à ne pas prendre en compte--------------

dans cette partie je vais détailler comment le travail était réalisé. Nous étions deux sur ce projet et avions donc en grande partie les mêmes méthodes de travail. Néanmoins, il y avait quelques divergences qui seront expliquées plus tard.

\subsection{Méthodes de travail employées}

Tout d'abord, nous allons voir les méthodes de travail que noous avons effectuées lors de ce stage. Il nous a été imposé de travailler en suivant une méthode agile de gestion de projet : la méthode SRUM.
Tout d'abord, rappelons en quoi consiste cette méthode de développement.

\subsubsection{Description de SCRUM}

Ce qu'il faut voir dans SCRUM, c'est qu'étant une méthode agile, les développeurs sont censés être très proches du client. Ensuite, SCRUM s'axe sur des sprint d'une durée d'une semaine dans le meilleur des cas, mais pouvant aller jusqu'à un mois.
Chaque sprint doit donner une version fonctionnelle du projet. Bien entendu, ce sont des versions non finales, et donc incomplêtes, mais on part du principe que dès le début, on se dotte d'une application qui fonctionne.

Néanmoins, entre les sprints, il faut définir les taches à effectuer. L'approche dans SCRUM est un peu particullière. En effet, cela s'organise sous forme d'un tableau où l'on appose des post-its. Ils sont découpés en trois catégories que l'on répartie verticalement. Tout en haut du tableau, nous plaçons les objectifs. Ils sont extrêmements généraux et tiennent en une phrase. Par exemple, dans notre cas, nous avions comme objectifs : Disposer d'une documentation en flash, Disposer d'une documentation lisible.
Ensuite, les objectifs se divisaient en plusieurs features. Les features étaint des qualificatifs sur les objectifs. par exemple : Je veux que l'application soit robuste, Je veux que l'application soit robuste.
Enfin, les features se divisaient en plusieurs user stories qui représentaient ce que les besoins que demanderaient différents acteurs. par exemple, si on se plaçait du côté d'un utilisateur, il pouvait poser certains besoins, comme par exemple : En temps qu'utilisateur, je veux comprendre rapidement le code documenté. mais il faut tenir compte d'autres acteurs. Par exemple : En temps que rédacteur, je veux générer ma doc facilement.
Ensuite, au dos du post-it, on y inscrivait la liste des tâches nécessaires à la réalisation de l'user storie décrite.
Ces tâches s'apparentaient aux tâches rencontrées dans la méthode XP. Elles sont censées êtretrès courtes. Les user stories devaient ensuite disposer d'un indice de vélocité. Plutôt que donner un indice absolue qui donnait une durée, cet indice est censé situer les user stories les une par rapport aux autres.

Cette méthode dispose aussi de postes, dont un SCRUM Master, sorte de tracker pour scrum, qui se charge de faire bien respecter l'utilisation de Scrum.
Au final, lorsqu'un sprint est terminé, l'équipe doit choisir de nouvelles user stories à réaliser.
C'est donc ainsi que doit s'effectuer un projet Scrum.

\subsubsection{Méthodes réellement employées}
L'inconvénien majeur était que nous n'étions que deux personnes sur ce projet, et le deuxième était lui aussi un novice en scrum, puisqu'il était aussi un stagiaire de l'université de Bordeaux 1. Nous étions donc extrêmement novice sur l'emploi de cette méthode. Un autre inconvénient à la réalisation de cette méthode de développement était le fait que nous ne disposions pas de scrum master. En effet, notre patron, Gérald Gainant, tenait partiellement ce rôle, mais était en même temps l'équivalent de notre client, et en plus se devait de faire son propre travail. Nous n'avions donc pas de suivi réel de notre travail sur scrum.
D'autres problèmes sont apparus assez rapidement. En effet, nous avons eu pour prérogative de travailler en binôme sur ce projet. Nous étions donc un seul binôme à travailler sur l'ensemble du projet et en utilisant scrum. Il nous est apparu assez vite que scrum n'était pas très adapté dans ce cas là. Le binômage non plus peut être. Néanmoins, pour le cas du binômage, cela pouvait se trouver être une aide précieuse car nous découvrions tout deux le langage actionscript. Donc nous nous nivelions l'un l'autre dès que l'un comprenait quelque chose.

Ensuite, nous avons préféré employer une méthode un peu différente lors de la réalisation des user stories. Nous avons créé une multitude de scénario afin de mieux cibler les situations auxquelles pourrait être confronté chaque acteur. 


\subsection{Principaux problèmes rencontrés}

\subsubsection{Défauts de SCRUM}

Enoncer les défauts de SCRUM.

\subsubsection{Limites rencontrées}
Faut trouver des limites sur notre logiciel. Peut être le licenciement en est une


---------------------------------test-------------------

\documentclass[a4paper,11pt]{report}
\usepackage[french]{babel}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}

\usepackage{a4wide}
\usepackage{pst-all} 
%opening

\title{
  \normalsize{\begin{flushright} MASTER 2 - Semestre 2 - 2009 \end{flushright}}
  \vspace{15mm}
  \hrule height 1mm
  \vspace{5mm}
  \Huge{\emph{Générateur de documentation pour le langage SIDL}}
  \vspace{5mm}\hrule height 1mm
  \vspace{1cm}
}

\author{
  MARCENAT Frédéric\\
  Chargé de stage : P. NARBEL\\
  Maître de stage : G. GAINANT
}

\date{}

\begin{document}

\begin{titlepage}
  \begin{figure}
    \vspace{1cm}
    \psset{unit=1in,linewidth=4pt} %paramétrage des unités pour pstricks
    \rput(1,0){\includegraphics[width=4cm]{Images/Bordeaux1.png}}
  \end{figure}
\end{titlepage}

\maketitle
\newpage

\begin{abstract}
 \input{resume}
\end{abstract}

\newpage
\tableofcontents
\listoffigures
\newpage

\section{Contexte de l'entreprise}
\input{entreprise}

\section{Définition du projet}
\input{definition-projet}

\section{Réalisation du projet}
\input{realisation-projet}

\section{Conclusion}
\input{conclusion}

\end{document}
